The present invention relates to a calling method for use when a caller makes a call to a callee in a one-to-one communication mode on the Internet.
Non-patent documents listed below are referred to in the following description:
[Non-patent document 1]
IETF RFC3261
[Non-patent document 2]
IETF RFC2327
[Non-patent document 3]
IETF RFC1889
In recent years, there has been a tendency to integrate exchange-based telephone communications networks into IP networks as part of a rapid advance in IP network technology. Telephone communications carriers have a plan to transfer data under voice (hereafter, simply referred to as DUV) on their own IP networks through Voice over IP (hereafter, simply referred to as VoIP). VoIP consists of two protocols, one protocol controlling call signaling and sessions and the other protocol controlling DUV transfer. The Internet Engineering Task Force (hereafter, simply referred to as IETF) created the specifications of a Session Initiation Protocol (hereafter, simply referred to as SIP), which is designated in IETF RFC3261, defining the method for call signaling and sessions. For example, the Session Description Protocol (SDP), IETF RFC2327, is applicable to the description of a session, including an agreement on a codec and transfer rate to be internally used in SIP.
Although no specific DUV protocol is defined in SIP, a Real-time Transport Protocol (RTP), which is designated in RFC1889, is commonly used.
According to IETF RFC3261, SIP is a protocol wherein a SIP message, consisting of a SIP Start Line, a SIP message header, and a SIP message body, is sent/received between two calling parties via a SIP server to establish agreement concerning the call signaling mode on the callee side, the voice, the image protocol and the bit rate to be used during conversation. Generally, the SIP Start Line describes the behavior of the message originator, the SIP message header describes the telephone number of a callee, the SIP server to be passed, and the Call-ID (call origination administration number), and the SIP message body describes the proposed voice, image protocol, and bit rate to be used during conversation.
Now, a procedure will be described briefly ranging from the start to the end of a two-party conversation through use of SIP, as described in IETF RFC3261, and the problems which arise with use of the procedure will be explained.
FIG. 1 is a network diagram illustrating a two-party conversation carried out through use of SIP. FIG. 2 is a sequence diagram illustrating the flow of a two-party conversation through use of SIP.
In FIG. 1, UserA, who belongs to a domain 3-1 and has an IP Telephone 2-1, makes a call to UserB, who belongs to a domain 3-3 and has an IP Telephone 2-2, via SIP servers 1-1 to 1-3.
First. UserA sends a Start Line INVITE and a SIP message for UserB to the SIP server A1-1 to establish a call with UserB (11). The SIP server A1-1, when receiving the INVITE message, adds a VIA header to its message header and transfers the SIP message to the SIP server B1-2. At that time, it also sends the SIP message containing a Start Line 100Trying to the IP Telephone 2-1, which is the callee (destination) of the message (12). The SIP servers B1-2 and C1-3, when receiving the SIP message, take the same actions and transfer the message to the UserB's IP Telephone 2-2.
The IP Telephone 2-2, when receiving the SIP message, sends a Start Line 180Ringing and a SIP message for UserA to the SIP server C1-3 (13) to sound a ringing tone on the UserB side. The SIP message containing a Start Line 180Ringing terminates at the IP Telephone 2-1 via the SIP server.
The IP Telephone 2-2, when UserB picks up the telephone receiver, sends a Start Line 200OK and a SIP message for UserA (14), which in turn, terminates at the IP Telephone 2-1 via the SIP server. The IP Telephone 2-1 sends back an acknowledge (ACK) signal in response to the message (15), and, when the ACK is received, a voice packet passes through a main signal path, enabling the two parties to initiate a conversation between them (16).
At the end of the conversation, UserA's IP Telephone 2-1 sends a Start Line BYE and a SIP message for UserB (17), which in turn, terminates at the IP Telephone 2-2 via the SIP server. In response to the message, the IP Telephone 2-2 sends back the ACK to the IP Telephone 2-1 via the SIP server (18). When the ACK is received, the conversation ends.
SIP is a protocol for sending and receiving SIP messages between a caller and a callee. A UserID and its DomainID are described in the headers, “From” specifying the caller contained in the message header, “To” specifying the callee, and Via specifying the SIP servers to be passed (proxy mode), because such information can be delivered as it is when the callee sends it back. To establish a session with the callee through SIP, the caller describes the IP address of his/her own terminal or an assigned DomainID in the headers.
With regard to VoIP, a protocol which informs the callee of no UserID (e.g. telephone number or UserID) of the caller, a mode has been proposed in IETF RFC3261 whereby the caller terminal creates a random UserID, registers the random UserID and the IP address of the terminal in the SIP server, and originates a call with the random UserID designated as the caller. Through this protocol, the whole procedure for making a Caller Anonymous Call is performed on the caller side.
If the IETF-supported communication mode, in which the caller makes a Caller Anonymous Call with his/her UserID concealed, is used in the SIP system, only the random UserID is registered in the SIP server. For this reason, the caller would make a Caller Anonymous Call not only to the callee, but also to the SIP server at the same time. The SIP server is difficult to control, and it is difficult to manage calls because it cannot guess the real UserID from the UserID registered in it. In the IP telephone services provided by communications carriers and others, user management is required, for example, caller identification, service permission/denial determination, and talk time management.
If a malicious third party intercepts a SIP message, he/she can identify the caller, the caller's SIP-URL, and the assigned DomainID as described in the SIP message, causing mischief, such as nuisance calls.
In addition, if the malicious third party knows the IP address of the IP Telephone, he/she can transfer a vast amount of packets to the IP Telephone after the end of conversation, making an attack, for example, DOS (Denial of Service), thereby disturbing processing on the equipment at a high possibility.